Vide Coding经验
AI 在上下文中认为文件是 A 状态，实际文件已经被开发者插手改成 B 状态了，然后你让 AI 基于它的认知继续修改，结果可想而知：要么产生混乱，要么 AI 需要再读一遍所有内容。有时候光是解决这种不同步带来的问题，花的时间就比写代码还多。
这一问题在另一篇文章1中也有提到
先规划还是先实施
如果你是个经验丰富的开发者，对项目架构已经有了清晰的认识，那么先进行充分的规划确实能让后续的实现更加顺畅。特别是对于那些需要遵循特定架构模式的既有项目，Plan Mode 能帮你确保 AI 生成的代码符合项目规范。
但如果你对某个技术栈完全不熟悉，或者正在做一个全新的探索性项目，那么“先干起来”可能反而是更好的选择。这种情况下，很多时候你根本不知道自己不知道什么。所以与其空想，不如让 AI 先写个原型出来，跑起来看看效果，发现问题再迭代。这种方式特别适合那些“短平快”的项目，或者你只是想快速验证一个想法。
先规划（不限于Claude Code的Plan Mode）的隐藏好处：
Plan Mode 还有个隐藏的好处：它能帮你整理思路。有时候你觉得自己想清楚了，但真要说出来或者写下来，才发现还有很多细节没考虑到。和 AI 的对话过程，其实也是一个自我梳理的过程。这算是“橡皮鸭调试法”的变种，在 vibe coding 时代依然很有价值。
迭代大小
小步迭代的好处显而易见（绝大部分情况下最好的选择）：
- 可控性高：每次只改动一小部分，出问题了也容易定位和回滚。
- 能够理解：你能跟上 AI 的思路，理解每一步在做什么。
- 质量保证：可以在每一步后进行测试，确保代码质量。
- 学习机会：通过观察 AI 的实现方式，你也能学到新东西。
大步迭代几个建议：
- 必须有完善的测试：采用 TDD 的方式，先写测试（当然这也是 AI 来写），再让 AI 实现功能。这样至少能保证基本的正确性。
- 做好版本控制：在开始之前创建新分支，随时准备回滚。
- 分模块进行：即使要一次性完成很多功能，也尽量按模块来组织，不要把所有东西混在一起。
- 交叉评审：AI 生成的代码看起来能跑，但可能隐藏着各种问题，对于生成的代码，不要照单全收。最简单的方式，就是找到另一个 AI，将变更喂进去，看看有什么需要改进的地方，这种迭代往往能收获不错的结果。
其他
先把大任务拆解成具体的小任务
这一点也在另外一篇中2提到也有提到
凡是重复了两次以上的类似 prompt 都应该用命令来表述！
AI 生成的代码，未经测试都是废品。